[ワークショップ] EC2 インスタンスのオートスケーリングをより最適化するためのワークショップ「Proactive auto scaling for optimal cost and availability」に参加しました（CMP335） #AWSreInvent

AWS re:Invent 2023

#AutoScaling

#AWS

いわさ

2023.11.30

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

いわさです。

AWS re:Invent 2023 でワークショップ「Proactive auto scaling for optimal cost and availability」に参加しました。

ワークショップの概要

re:Invent 2023 公式サイトのワークショップ概要を Amazon Translate で翻訳した内容が以下となります。

Amazon EC2 Auto Scaling グループは、ユーザーが AWS クラウドの伸縮自在性のメリットを活用できるようにします。

このワークショップでは、EC2 Auto Scaling の最新のイノベーションを最大限に活用して、ウェブアプリケーションの可用性を低コストで向上させる方法を学びます。

具体的には、予測スケーリング、動的スケーリング、ウォームプール機能を組み合わせて、需要の変化に応じてキャパシティーを自動的に起動および終了する方法をご覧ください。

応答性が高く先を見越したスケーリングにより、1 日のどの時間帯でも必要な数のインスタンスのみを実行できるため、EC2 インスタンスのオーバープロビジョニングによるコストを削減できます。

気になる内容だったので早速ワークショップに参加してみると、「お前たちのオートスケーリングではスパイクアクセスに耐えられないだろう？」という内容から始まります。

EC2 をオートスケーリングさせるための Auto Scaling Group にはいくつか高度な機能があります。
予測スケーリング、動的スケーリング、ウォームプール、存在は知っていたけど使いこなせていないという方も多いのでは無いでしょうか。
今回このあたりを学ぶ良い機会だと思い、参加してみることにしました。

このワークショップを通してどういうことが経験出来るのか紹介したいと思います。

スピーカー

Ankur Sethi
Steve Cole

LEVEL

ワークショップの内容

ワークショップの流れですが、CloudFormation を使ってオートスケーリンググループ + EC2 の環境がデプロイされます。（ワークショップ内で提供される AWS アカウントの場合はデプロイ済み）

開始時は希望するキャパシティが次のように 0 となっていました。

このオートスケーリンググループに対して予測スケーリング・動的スケーリング・ウォームプールを追加で構成し、スパイクアクセスに対応しやすくする構成に近づけていくワークショップとなっています。

内容としてはこちらで公開されている、「RUNNING EFFICIENT AND RESILIENT WORKLOADS WITH AMAZON EC2 AUTO SCALING」と同じものと思われます。

予測スケーリングポリシー

まずは予測スケーリングを構成します。

予測スケーリングでは機械学習を使用して CloudWatch の履歴データに基づいて、将来必要な需要を事前に予測するものです。
スパイクの発生頻度など、時系列の法則があるものだと予測スケーリングで適切なキャパシティコントロールが出来るというコンセプトのものです。

ただし、予測スケーリングポリシーは最低でも 24 時間のメトリクス履歴が必要となります。

このワークショップでは事前にカスタムメトリクスを過去数日分デプロイしておき、そのカスタムメトリクスをベースとした予測スケーリングを設定しています。

こちらをもとにオートスケーリンググループで予測スケーリングポリシーを設定します。

ワークショップ内では時間の関係で実際にキャパシティの変化が発生する状況を観察は出来ないのですが、予測メトリクスでのキャパシティ変化と負荷予測データについて確認することが出来ます。

予測スケーリングポリシーを導入し、需要の増加に先立ってアプリケーションの応答性を確保するというのがひとつめのポイントです。

動的スケーリング

続いて、動的スケーリングを構成します。

ワークショップを通して改めて知ったのですが、予測スケーリングで予測よりも実際のトラフィックが少なかった場合にスケールインはされません。同様に予測よりも負荷が高い場合でもスケールアウトしてくれません。

そのため、予測スケーリングで予想出来なかった需要の急増などに対応するために動的スケーリングポリシーを組み合わせるとより最適なスケーリングポリシーとなります。

こちらについても予測スケーリングポリシーと同様にワークショップ内では実際の動作確認が出来ないのですが、予測スケーリングポリシーを補うために動的スケーリングポリシーを組み合わせるというのがふたつめのポイントです。

ウォームプール

オートスケーリングポリシーにはウォームプールという機能があります。

スケールアウトによってインスタンスが追加されるとき、通常新しく EC2 インスタンスが作成されます。
その際に初期化処理やら何やらが発生するので、ミドルウェアやアプリケーションに依存して利用可能になるまでの時間が長くなる場合があります。
その立ち上がり遅い問題を解決するために余裕をもって多めにインスタンスを起動しておく、あるいは強めのインスタンスを起動しておくという、いわゆるオーバープロビジョニング状態を採用する場合があるかもしれません。

ウォームプール機能ではオートスケーリンググループの最大キャパシティの範囲までウォームアップしたインスタンスを事前に用意しておきます。
ウォームアップインスタンスは起動・休止（OS が対応している場合）・停止からモードを選択することができ、停止の場合でも新規作成される場合と比べて大幅に利用可能になるまでの時間を短縮出来ることが期待出来ます。

さらに、停止状態のウォームアップインスタンスは EBS や Elastic IP の料金のみで済むのでオーバープロビジョニングよりもコスト効率が良いが、なかなか起動が早いというメリットがあります。

ウォームプールなしの場合

このワークショップではライフサイクルフックを構成することで、インスタンスの標準の立ち上がりが遅い状態を作っています。

上記構成で EC2 インスタンスの起動時間を次のコマンドで計測しています。
146 秒かかったようです。

$ activities=$(aws autoscaling describe-scaling-activities --auto-scaling-group-name "ec2-workshop-asg" | jq -r '.Activities[0]') && \
> start_time=$(date -d "$(echo $activities | jq -r '.StartTime')" "+%s") && \
> end_time=$(date -d "$(echo $activities | jq -r '.EndTime')" "+%s") && \
> activity=$(echo $activities | jq -r '.Description') && \
> echo $activity Duration: $(($end_time - $start_time))"s" || echo "Current activity is still in progress.."
Launching a new EC2 instance: i-06dffe2e100a97f88 Duration: 146s